Amazon EC2のStandard RI/Convertible RIとキャパシティ予約
リザーブドインスタンスの機能アップデート
昨日、リザーブドインスタンスに大きなアップデートがありました。今までのRIをStandard RI、新しいRIをConvertible RIと呼ぶようになりました。また、キャパシティ予約の有無を指定できるようになりました。
AWSのホームページでも以下のように新しい表記に変更されています。
Standard RIとは
Standard RIは、従来と同じように、1年/3年、NoUpfront/PartialUpfron/AllUpfrontなど指定できるようになっていますが、今回新たに、スコープ指定として、AZの他にRegionを選択できるようになりました。Region指定は、AZに依存せずに割引が適応されるため、より広範囲に割引が適用されるようになります。
例えば、1aゾーンで購入したRIがあったとします。その後、1aのEC2をターミネートして、1cゾーンで全く同じタイプのEC2を利用することになった場合、以前は、AZの変更という手続きを別途行う必要がありましたが、今回の新しいRIでRegion指定することで、AZに関係なく割引が自動的に適用されるようになります。この設定変更はいつでも行うことができ、変更に伴うコストはありません。
Convertible RIとは
新しく出来たConvertible RIは、従来RI購入時にサーバーの詳細を指定する必要があって後から構成変更が難しかったのを、いつでも簡単に交換できるようにしたものです。交換そのものの追加コストは掛かりません。交換に伴うインスタンスタイプやOSの差分コストのみが発生します。これにより、長期間同じサーバー種類やOSを決めてから使うというRIの使い方ではなく、変更があれば後から交換できるようになりました。ただし、自由に構成を交換できるため、Standard RIに比べて少し割引率が下がっています。
なお、こちらもキャパシティ予約の有無を指定できるようになっています。
キャパシティ予約の有無
従来のRIは、長期利用の宣言による大幅な割引と、キャパシティ予約という側面がありました。キャパシティ予約とは、サーバーリソースが有限であるデータセンターにおいて、最大容量を超えるような起動リクエストがあった場合、キャパシティ予約の契約をしているインスタンスの起動を優先する仕組みです。もちろん、既に起動しているものは勝手に落ちたりしません。
実際のところ、AWSは世界最大規模のデータセンターを保有しています（たぶん）ので、キャパシティ不足は起こりづらいのですが、例えば、大規模災害とか大規模障害が発生した際に、あるAZが丸ごと疎通不能に陥り、システムがフェイルオーバーするときには、キャパシティ不足が起こるかもしれません。または、最新CPUを積んだ非常に新しいインスタンスタイプにおいて、まだ十分にサーバー台数を用意できていない場合もあるかもしれません。
それぞれレアケースではありますが、キャパシティ予約が必要な要件もあることと押さえておきましょう。
「割引」と「キャパシティ予約」を分けて考える
さて、RIにおいて、スコープをAZを指定するか、Regionを指定するかの違いは、上記の説明の通り、キャパシティ予約をするかどうかとなります。RIを利用する多くの方は、大幅な割引を得るために権利を購入される場合がほとんどだと思います。今回のRIのアップデートは、ただ単に制約が緩和されるだけではなく、「割引」と「キャパシティ予約」を分けて考えることができるようになったと考えると、理解しやすいと思います。
Standard RI：スコープをリージョンに変更する
さっそく、実際に購入済みで有効になっているStandard RIのスコープを変更してみましょう。メニューから、RIの変更を選択します。
確定ボタンを押すと成功したメッセージが表示されます。
しばらく待ちますと、既存のRIがリタイアして、新規にRIのレコードが作成されていることがわかります。
こちらが以前のもの
こちらが新しいもの
ポイントとしては、スコープを変更する前と後を足すと、当初購入した年数になることです。イメージ図を以下に示します。
Convertible RI：RIを交換する
続きまして、新規にConvertible RIを購入して、その後、他の異なるインスタンスに変更してみたいと思います。
今回は、t2.nanoのLinux(VPC)をConvertible RIとして購入しました。そして、メニューからRIの交換を選択します。
今回は、LinuxからWindowsへインスタンスを"交換"してみたいと思います。すると、インスタンス交換に伴う差額が表示されます。
ここでのポイントとしては、購入済みのRIの支払い総額を超えるRIの交換しかできないことです。今回は、t2.nanoのLinux(VPC)からt2.nanoのWindowsへの変更となりましたので、減額では無く増額となるため普通に交換をすることができました。
どのように交換されるのかイメージ図で表現します。t2.nanoのLinuxから、m3.largeのWindowｓに交換し、更にxxx.largeのRHELに交換する例です。
単価の安いインスタンスに交換するときはどうする？
ここでひとつ疑問が湧きます。金額が大きいRIへの交換しかできないとすると、後々困ってくるのではないかと。やってみてわかったのですが、単価の安いインスタンスを指定するのであれば、台数を増やすことで対応可能です。以下の例は、t2.nanoのWindowsから単価の安いt2.nanoのLinuxに交換する例です。
インスタンスカウントが2になっていることが分かりますね。以上により、RIの交換は総額が少しでも超えるのであれば、変幻自在に交換可能であることが分かりました。
また、繰り返しとなりますが、Convertible RIにおいても、スコープの変更が可能です。
No Upfrontへダウングレード交換はできない
Convertible RIでインスタンスを交換する際に気をつけるポイントがあります。それは、No Upfrontです。No Upfrontはその名の通り、初期費用がありません。利用期間を宣言するのみです。インスタンスを利用してもしなくても毎時間少額の費用が発生しますが、トータルで見ると割引となります。
例えば、Convertible RIを購入する時、Partial UpfrontやAll Upfrontを選択したとします。次に、RIの交換でNo Upfrontを選択して決定をします。
すると、交換が失敗と表示されます。
エラーの理由は、交換元となるRIの初期費用よりも交換後が下回っているからです。RIの交換は、初期費用が高い必要があります。RIのダウングレードする際には、台数を増やせば良いとお伝えしましたが、0は何倍しても0なので、これは実現できません。注意しておきましょう。
No Upfrontによる上手い波乗り
No Upfrontは、初期費用が掛からずに宣言するだけで20〜30%程度の割引が適応されます。これは、要するに、3年間AWSを設定金額以上で利用を宣言するだけで安くなることを意味します。大変オトクになる可能性を秘めています。ただし、設定したRIが適用され続けるようなインスタンスの連続起動により割引が最大限適用されますので、起動するインスタンスタイプが頻繁に変更されたり、起動と停止を繰り返すような用途には不向きです。また、安定運用しているインスタンスが変更された場合、追従してRIを交換し続ける"運用"をする必要があります。次の波に乗ることで割引メリットを受けつづけることができるわけです。
EC2が値下げしたらどうなるか
将来、EC2の値下げが発表された場合、購入済みのRIの利用費自体はおそらく値下げされません。RIは購入時に価格が決まるためです。そのため、今まではRIの購入をためらう人が少ならからずいました。今回、RIの交換という機能ができたことによって、EC2の値下げにRIが追従できるようになります。ただし、注意があります。全く同じRIのタイプへの交換だと値下げですから変換前から変換後を引き算するとマイナス値になってしまい、このまま交換はできません。そこで、一旦2つ以上の安いRIに分割変換してから、改めて片方を元のRIのタイプに変換します。以上により、もしEC2の値下げが発生した場合には、元のRIを使いつつ、別のRIを無料で使えるようになります。過去に支払ったRIの費用は返ってきませんが、値下がった分を他のRIに充てることができるのは嬉しいですね。
現状のリリースでは、Convertible RIの数を変更する際に任意の数を指定したり、リージョン指定の一部をゾーン指定にするとか、細かいことはできませんが、今後の機能追加に期待ですね。
まとめ
今回のRIアップデートは、全てのAWS利用者にとって重要であると思っています。ぜひ、活用してクラウドのメリットを最大限受けましょう。
最後に、私の独断と偏見により、保険商品のような感じで今回のRIアップデートについてイメージ図で表してみましたw
参考資料
EC2 Reserved Instance Update – Convertible RIs and Regional Benefit
